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niversal serial 
^^^^^^^r bus ( USB ) promises 
to be the next major 
advance in PC function- 
ality, completing the PC's transition to 
a plug-and-play system. But, for all its 
possibilities, USB is bit of a mystery. 

For the average engineer with an 
idea for a USB product or who has been 
commanded to convert an existing 
system, the journey to enlightenment 
can be an arduous struggle. Rather than 
merely providing information on USB, 
we want to show you how to get your 
USB device up and running. 

As a high-speed bus for connecting 
external devices to the PC, USB is the 
next step for external peripherals on 
Windows and Macintosh computers. By 
allowing hot-plug installation, recon- 
figuration becomes less of a hassle. 

USB enables 127 devices to be on 
the bus simultaneously. This arrange- 
ment solves the problem of limited 
serial ports. 

USB operates at 12 Mbps (there is a 
low-speed mode of 1.5 Mbps for some 
devices), and it supports isochronous 
and asynchronous data transfers. Be- 
cause USB devices can be bus powered, 
the transformer ganglion behind the 
computer can be reduced. 

PC users now have a simple user- 
friendly peripheral bus that supports up 
to 127 devices and that can be installed 
without configuring or altering their 



Before 
getting into" 
the nitty- 
gritty of working on 
Universal Serial Bus 
projects, you need to 
know the basics. But 
Mike, John, and Jon 
offer more than an 
intro to USB. Their 
demo gets you ready 
to work on your own. 
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current system. Gone are the days of 
figuring out which interrupt settings 
and I/O addresses were available and 
altering the device's settings to fit the 
ava ;,1 ble resources. 

.h USB, you just plug the device 
into the port. The OS takes care of the 
rest. There are no jumpers, power 
packs, powerdowns, resets, or taking 
the case off. The PC automatically 
installs the appropriate driver and 
configures the device as needed. 

HOW DOES USB WORK? 

RS-232 serial communication with 
UARTs, transfer rates, stop bits, and 
so on traces its heritage back to me- 
chanical devices in the days of teletype. 
In the heyday of TTY, you could repair 
a UART with a wrench. Adjusting the 
transfer rate was more like tuning a 
car than working on electronics. 

USB doesn't represent an electronic 
analog of a mechanical system. In a 
USB system, the line between hard- 
ware and software function is blurred. 
USB exploits the full potential of a 
computerized communication system. 

The two sides of a USB system are 
the Hevice and the host. The device side 
coi s of the USB device (e.g., modem 
or printer), which usually contains a 
USB microcontroller (e.g., the Intel 
'930) and the code to properly initiate 
USB communication to the host. The 
host side is the PC running an OS that 
supports USB. The device and host 
communicate over the USB cable. 



USB devices can be self-powered or 
bus powered, so they can be produced 
without including a bulky wall-mount 
transformer. The device gets its power 
from the host computer or USB hub. 

BUS TOPOLOGY 

USB uses a tiered/star bus topology 
in which each device plugs into a hub. 
The hub is a traffic cop that enforces 
the low-level rules of the bus. Figure 1 
shows the physical arrangement of a 
USB system. For the most part, hubs 
are transparent. 

Classes are the device categories 
that share common I/O requirements. 
In USB there are currently 1 1 classes: 
common class, audio, communications, 
hub, human interface device (HID), 
image, monitor, physical interface 
device (PID), power, printer, and storage. 

Classes introduce a set of standard 
drivers native to the OS (Windows 98) 
and enable you to use them as is, write 
your own driver, or have a mini-driver. 

PACKETS 

A packet is a combination of special 
fields. All packets begin with the Sync 
field to synchronize the phase-locked 
loop and have a packet identifier (PID) 
that helps USB devices determine, the 
kind of packet being sent. The packet is 
followed by address information, a frame 
number, or data. There are four types 
of packets,- each has several subtypes. 

The first packet type — the token, 
shown in Figure 2a — is a 24-bit data 
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Figure 1 —This diagram shows the physical arrange- 
ment of a USB system. 

packet that represents what is happen- 
ing over the bus. The first eight bits 
represent the packet identifier. The 
next seven bits are the address of the 
device that the host is communicat- 
ing with. The next four bits are the 
endpoint address, which is where the 
data is going in the device. And, the 
last five bits are the CRC to check the 
token for errors. 

There are four types of tokens — In, 
Out, Start of Frame (SOF), and Setup. 
Check the glossary of terms in Design 
Forum for more details. An SOF 
packet is illustrated in Figure 2b. 

As you see in Figure 2c, data pack- 
ets contain PIDs for further data error- 
checking. Data packets alternate 
between DAT AO and DATA1. The 
only exception to this format is the 
Setup packet, which always uses the 
DATAO packet. 

Data packets have a format of the 
DATAO/ 1 PID followed by the data, 
which ranges in length from to 1023 
bytes. The packet is 
checked with a 16-bit 
CRC field. 

The handshake packet 
is shown in Figure 2d. 
These packets inform the 
sender of the data as to 



c) 



Packet identifier 
DATAO: bO01 1 
DATA1:b1011 
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Packet identifier 
ACK:b0010 
NAK:b1010 
STALL: b1 110 
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00000001 
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Figure 2— These diagrams show 
four different types of packets: token 
(a), SOF (b), data (c), and hand- 
shake (d). 
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USB device 
Vendor ID: ABCD 
Product ID: AA 
Assigned address: 3 



USB device 



Device 
ports 




USB 






Root 


port 


■* 




hub 



USB device 
Vendor ID: 123 
Product ID: AA 
Assigned address: 5 
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Hub informs host 



1 . Device is attached to a hub port. 

2. Hub notifies host of change-of-port status when 
polled for status updates. 

3. Host queries the hub as to the change in port 
status. 

4. Host issues a port enable and reset c 
for the port. 

5. Device now in powered state and r 
default address. 

6. Host retrieves the device descriptor and deter- 
mines the maximum packet size for endpoint 
zero. It also retrieves the VID and PID to know 
what device driver to use with the device. 

7. Host assigns unique address to USB device. 

8. Host retrieves the configuration descriptors. 
Based on available power and bandwidth, the 
host assigns a configuration to the device. 

9. The device is now addressed, configured, and 
ready to use. 



Figure 3— This diagram and the accompanying list illustrate the enumeration of a USB device. 



the condition of the received data 
packet. Handshake packets are ACK, 
NAK, and STALL. 

The special preamble packet estab- 
lishes low-speed communication on 
the bus. This token is sent full speed 
to the hubs, and the hubs then enable 
their low-speed outputs. 



DESCRIPTORS 

The descriptor includes general 
information about the device. The 
Vendor ID and Product ID fields play 
the key role in the enumeration of the 
device. The descriptor also informs the 
host about the number of configurations 
of the device. 
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Configuration descriptors tell the 
host the number of interfaces, the 
device's power requirements, and its 
attributes. Interface descriptors are the 
number of endpoints and what class 
they belong to as well as the interface 
protocol. 

Endpoint descriptors describe the 
direction and attributes of the end- 
points belonging to a specific interface, 
including the address of endpoint, 
direction of endpoint, attribute of 
endpoint, and maximum packet size. 

DATA TRANSFERS 

A transfer or transaction consists 
of a number of packets moving back 
and forth along the bus between the 
host and a device. There are four types 
of data transfers in a USB system: 

• control— controls the bus, bidirection- 
al, setup, data, status 

• bulk — asynchronous data, bidirec- 
tional, CRC 

• isochronous — time-critical data, no 
CRC, unidirectional, up to 1023 bytes 
per frame, guaranteed bandwidth 
per frame 

• interrupt — receives data at timed 
intervals, input only, 1-255-ms 



Enumeration is the bus-configura- 
tion process, which takes place any- 
time the bus is started or a device is 
plugged into or unplugged from the bus. 
This process is shown in Figure 3. 
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The whole USB system is not pro- 
vided by any one vendor. The OS 
provides some parts; other parts come 
from third parties and the developer. 

For the next few years, most USB 
development projects will have to func- 
tion with both Windows 95 and 98. 
There are some key items to be aware 
of when using USB with Windows 95. 

Windows 95 doesn't have native USB 
support. You must have OSR 2.1 build 
1214 or better installed on the system. 

Windows 95 also has some minor 
bugs. One such bug is when the USB 
device has no alternate settings. If this 
occurs, Windows 95 freezes up when 
the device is unplugged. 

Windows 98 handles USB right out 
of the box and resolves the above- 
mentioned bug. It also has a program 
to assist in developing USB peripherals. 
usbview.exe enables you to monitor 
the activity on the USB bus as well as 
get the device descriptors. 

END-TO-END EXAMPLE 

As promised, here's an example of 
how to get a USB device working. 



Using a commercially available evalu- 
ation board, the goal of this system is 
to blink LEDs on the eval board from 
the PC and to blink indicators on the 
PC screen from the eval board. 

For this project, you need the An- 
chor Chips EZ-USB evaluation kit V.C 
or better, the USB specification, Win- 
dows PC with USB support, Windows 
95 (OSR 2.1 build 1214 or better) or 
Windows 98, and Visual C++ or Visual 
Basic (V.5.0 or better). To produce 
drivers, you need Windows 98 and the 
Windows 98 DDK. 

We hooked up Port A of the Anchor 
Chips device to a switch/LED circuit 
and created a DLL using the driver's 
IOCTL functions. A VB program calls the 
DLL and gets the data from the driver. 
Basically, VB requests device descriptors 
by calling the DLL (passes an empty 
pointer to buffer) and the DLL calls the 
driver using IOCTL_Ezusb_GET_ 
DEVICE_DESCRIPTOR. 

Data is passed to a buffer, and the 
buffer is filled and returned to VB. The 
driver calls the USBD.SYS driver to 
communicate with the device and OS. 



HARDWARE TESTING 

When you get your development 
board, you want to make sure the 
hardware works. First, install the 
software, which puts the EZ-USB 
driver into the Windows system and 
the install information (INF) file into 
the INF directory. 

The I N F file informs Windows as 
to what driver to load for the particu- 
lar vendor ID (VED) and product ID 
(PID) combination. The USB Imple- 
menters Forum provides the VID ; you 
assign the PID. 

Once the software is installed, plug 
in the USB device with the included 
USB cable. It's impossible to hook up 
the cable backwards because the cable 
has two different connectors (A and B). 

When the device is connected, the 
red light lights up, signaling that the 
board has power. Windows informs 
you that it has found new hardware, 
finds the appropriate I N F file, and 
installs the driver for the new device. 

All information concerning driver 
and VDD/PID combinations are in the 
Windows system registry. If, during 
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Listing 1—77* Visual Basic code calls a DLL to get the device descriptor. 



Type define to overcome VB's limitation 
in not having unsigned 16-bit numbers 



Type define for USB Device Descriptor 



Private Type Unsignedlnt 

lobyte As Byte 
hi byte As Byte 
End Type 

Private Type LongData 

Number. As Long 
End Type 

Private Type USB_DD 

Descri ptor_Length As 

Descri ptor_Type As Byte 

Spec_Release As Unsignedlnt 

Devi ce_Cl ass As Byte 

Device_SubClass As Byte 

Devi ce_Protocol As Byte 

Max_Packet_Si ze As Byte 

Vendor_ID As Unsignedlnt 

Product_ID As Unsignedlnt 

Device_Release As Unsignedlnt 

Manufacturer As Byte 

Product As Byte 

Serial_Number As Byte 

Number_Configurations As Byte 
End Type 

•DLL functions used to communicate with USB device 

Private Declare Function ReadBulkByte Lib "lusher_USB.dll" (ByRef InByte As Byte, 

ByVal PipeNumber As Byte, ByVal DeviceDriver As String) As Integer 
Private Declare Function wri teBul kByte Lib "lusher_USB.dll" (ByVal OutByte As 

Byte, ByVal PipeNumber As Byte, ByVal DeviceDriver As String) As I ntegerPr i vate 
Declare Function GetDevi ceDescri ptor Lib "lusher_USB.dll" (ByRef DevDes As USB_DD, 

ByVal DeviceDriver As String) As Integer 
' get device descriptor and parse it into appropriate fields 
Private Sub Get_USB_Devi ce_Descri ptor( ) 

' Gets device descriptor from the USB device as well as verify 
that USB is communicating correctly and that correct 
source code is running 

Dim CheckData As Byte 

Dim ProdID As LongData 

Dim VendID As LongData 

Dim SpecRel As LongData 

Dim DevRel As LongData 

Dim USB_Device_Descriptor As USBJD 

Dim Result As Integer 

Result = GetDeviceDescriptor(USB_Device_Descriptor, "\\.\ezusb-0") 

' If all transactions met with success, then set up screen and 

allow user interaction 
' Else alert user to the fact that no USB device is present and 

do not allow user interaction 
If Result = Then 

Call USBError ' Informs user of error and set form attributes 

to of f 1 ine mode 

Exit Sub 
End If 

Status. Caption = "USB Device Connected" 
Status. ForeColor = &HFF00& 

LSet ProdID = USB_Device_Descriptor.Product_ID 

LSet VendID = USB_Devi ce_Descri ptor . Vendor_ID 

LSet SpecRel = USB_Device_Descriptor.Spec_Release 

LSet DevRel = USB_Devi ce_Descri ptor . Devi ce_Rel ease 

DesForm. Type. Caption = USB_Devi ce_Descri ptor . Descri ptor_Type 

DesForm. Spec. Caption = SpecRel . Number 

DesForm. Class. Caption = USB_Devi ce_Descri ptor . Devi ce_Cl ass 
DesForm. Subclass. Caption = USB_Devi ce_Descri ptor . Devi ce_SubCl ass 
DesForm. Protocol .Caption = USB_Devi ce_Descri ptor . Devi ce_Protocol 
DesForm. PacketSize. Caption = 

USB_Devi ce_Descri ptor .Max_PAacket_Size 
DesForm. VendorlD. Caption = Vend I D . Number 
DesForm. ProductlD. Caption = ProdID . Number 
DesForm. DevRel .Caption = DevRel . Number 
ProductlD. Caption = ProdID . Number 
VendorlD. Caption = VendID. Number 
End Sub 

' Example calls to read and write functions 
Result = WriteBulkByte(Data_Out. 0, "\\ . \ezusb-0" ) 
Result = ReadBul kByte( Data_In, 7, " \\ . \ezusb-0" ) 
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Listing 2-This example DLL handles calling the EZ-USB driver. 



II ReadBul kData ( BYTE *OutBuffer, BYTE NumberOf Bytes , BYTE PipeNumber, 
// LPSTR DeviceDriver) 

// Function reads data from specific pipe over USB port for device in question 
int_stdcall ReadBul kDatatBYTE *OutBuffer, BYTE NumberOf Bytes , BYTE PipeNumber, 
LPSTR DeviceDriver) 

{ 

HANBLE hUSBJeviceHandle; // Declare variables 
DWORD nBytes = 0; 
BOOL bResult; 

BULK_TRANSFER_CONTROL bul kControl ; 
BYTE Input[64] ; 
BYTE index; 

bul kControl .pi peNum = (ULONG)PipeNumber; 

if (NumberOfBytes > 64 I I NumberOf Bytes < 1) 

// Limit atnmount of transfer to 64 bytes maximum 

// If greater than 64 or less than 1 then return an error 

{ 

return 0; 

} 

// Get handle to USB device in question 

hUSB_DeviceHandle = CreateFi 1 e( Devi ceDri ver , GENERIC_WRITE , 

FILE_SHARE_WRITE, NULL, P EN_EX I STING , 0, NULL); 
if(hUSB_DeviceHandle == INVALID_HANDLE_VALUE) 

{ 

return 0; // If not a good handle then abort! 



// Else it is a good handle; read data to USB pipe by calling system driver 

bResult = Devi eel oControl ( hUSB_Devi ceHandl e , IOCTL_EZUSB_BULK_READ , &bul kControl , 

si zeof ( BULK_TRANSFER_C0NTR0L ) , &lnput[0], NumberOfBytes, XnBytes, NULL); 
CloseHandle(hUSB_DeviceHandle) ; // Close handle 
// Fill result with that of input array 
for (index = 0; index < NumberOfBytes; index++) 
{ 

*0utBuffer = Input[index] ; 
OutBuf fer++; 

} 

return ( i nt )bResul t ; // Return our result: success or failure 



// WriteBulkData(BYTE MnBuffer, BYTE PipeNumber, LPSTR DeviceDriver,) 

// Function writes data from specific pipe over USB port for device in question 

int _stdcall Wri teBul kData ( BYTE MnBuffer, BYTE NumberOfBytes, BYTE PipeNumber, 
LPSTR DeviceDriver) 

« 

HANDLE hUSB_DeviceHandle; // Declare variables 
DWORD nBytes = 0; 
BOOL bResult; 

BULK_TRANSFER_CONTROL bul kControl ; 
BYTE 0utput[641; 
BYTE index; 

bul kControl . pi peNum = ( UL0NG) Pi peNumber ; 

// Limit ammount of transfer to 64 bytes maximum 

// If greater than 64 or less than 1, return an error 

if (NumberOfBytes > 64 I I NumberOfBytes < 1) 

{ 

return 0; 

} 

// Fill output array with that of input buffer 
for (index = 0; index < NumberOfBytes; index++) 
{ 

OutputCindex] = *InBuffer; 
InBuf fer++; 

> 

// Get handle to USB device in question 

hUSB_DeviceHandle = CreateFi 1 e( Devi ceDri ver , GENERIC_WRITE, 

FI LE_SHARE_WRITE , NULL, 0PEN_EXISTING, 0, NULL) ; 
i f (hUSB_DeviceHandle == I NVALI D_HANDLE_VALUE ) 
{ 

return 0; // If not a good handle, abort! 

} 

// Else it is a good handle; write data from USB pipe by calling system driver 
bResul t = Devi eel oControl ( hUSB_Devi ceHandl e , IOCTL_EZUB_BULK_WRITE , &bul kControl , 

si zeof ( BULK_TRANSFER_C0NTROL ) , &0utput[0], NumberOfBytes, fcnBytes, NULL); 
CloseHandle(hUSBJ)eviceHandle) ; // Close handle 
return ( Int Jbftesu] t ; // Return our result: success or failure 

1 
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development, you need to delete these 
entries, they are located at HKEY_ 
LOCAL_MACHINE\Enum\USB and HKEY_ 
LOCAL_MACHINE\System\Current- 
ControlSet\Services\Class\USB. 

You can use regedi t . exe to edit 
and browse the registry entries on your 
computer. You can now unplug and 
replug the device as much as you need. 
Until you delete the registry entries, 
Windows remembers what driver to 
load and doesn't inform you of any 
hardware detection again. This step is 
called enumeration. 

Enumeration is when the OS recog- 
nizes that there is new hardware on 
the bus and determines its particular 
needs. The appropriate driver is then 
loaded and it gives the device a unique 
address. Enumeration takes place each 
time you plug a device on the bus and 
on bootup of Windows. 

At this point you should try the 
software package that comes with the 
evaluation kit. EZ-USB Control Panel 
lets you get the descriptors from the 
USB device, download firmware to the 
device, and run the Keil debugger. 

THE GOAL 

Our goal is to build a demo of a 
working USB device. The concept is 
that a user application sends data to a 
USB device and vice versa. Our USB 
device is the Anchor Chips development 
board running firmware we created. 

On the host side, we have an appli- 
cation made using Visual Basic. The 
program communicates with the device 
via the general-purpose driver (GPD) 
from Anchor Chips and a DLL we 
created to implement a bridge between 
the user interface (VB) and the GPD. 

The user interface is an experiment 
board with four DIP switches and four 
LEDs. The user selects a four-digit 
binary combination that appears on 
the LEDs and vice versa for the DIP 
switches. 

In our VB program, we call functions 
in a DLL that communicates with the 
GPD. Listing 1 shows how to call the 
DLL that communicates with the USB 
device. It also shows how to parse up 
the device descriptor and read and 
write a byte from the USB device. 

A DLL was written to communicate 
between the Visual Basic program and 
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The DLL does the necessary commu- 
nicating with the system driver and if 
there is an error, responds to the calling 
application with an error status. This 
a' ^ement provides an easy-to-use 
interface to the GPD. 

FIRMWARE 

For your USB microcontroller, we 
recommend you have the full version 
of the C compiler because the example 
files may exceed the evaluation limit 
of most evaluation-level compilers. 
Most of the code needed to communi- 
cate with the host is already written. 
Just fill in your peripheral and I/O code. 

The development kit has two firm- 
ware files called PERI PH . C and FW . C. 
These files (supplied by Anchor Chips) 
contain the framework for the whole 
8051 -based USB control code. The 
PERI PH. C source file contains the poll- 
ing loop code segment, as well as the 
endpoint interrupts for communicating 
with the host. You merely write your 
peripheral code in the poll loop. 

When data is to be exported, a set 
of ISRs is called (seven in and seven 
out). These are the endpoints of the 
c uunication pipes. In the initial- 
iz^on section of the code, you need 
to set the direction of the port pins. 
For our example, port A is used. The 
upper nibble is input and the lower 
nibble is output. Listing 3 shows ex- 
ample routines from PERIPH.C. 

In USB the host initiates all com- 
munications. If the device has some- 
thing to tell the host, it must place the 
data into an output array (IN1BUF[0]). 

After the firmware is finished, it 
must download to the chip because 
Anchor Chips' USB paradigm calls for 
the device-side application code to be 
transferred on startup of the processor. 
There are two methods for downloading 
the firmware— BO load and B2 load. We 
describe BO here. 

The micro is basically a state ma- 
chine that does simple USB tasks 
without 805 1 code. Using the BO pro- 
tocol, the firmware is sent over the USB 
to the chip and an external EEPROM 
contains the device descriptor (VID and 
P' -1 This information tells Windows 
tc jad a driver. 

The driver was made using the 
ezloader.sys driver source file, 

www.circuitcellar.eom 



which lets you implement your firm- 
ware as part of the driver. The device 
is enumerated to download the firm- 
ware to the micro's RAM. 

The micro reenumerates and reports 
a new device descriptor. We used the 
same VID but different PIDs (x8000 for 
download, x8001 for device). The new 
VID/PID combination tells Windows 
to load the real driver (EZUSB . SYS). 

An INF file tells Windows which 
VID/PID combination goes with each 
driver. Listing 4 is a typical I N F file 
entry for the VID/PID combo. Our VID 
is 0x06E5, and the PIDs are 0x8000 
and 0x8001. The sample INF file tells 
Windows which drivers to load accord- 
ing to the VID and PID information that 
the system retrieves from the device. 

READY TO GO 

Basically, you treat most of the 
firmware code as if you were in regu- 
lar 8051 development, except that the 
code resides in the POLL loop, not MAIN. 
There are ample instructions in the kit 
manuals. The GPD is well documented, 
and their program handles the rest. B 



Mike Zerkus has 15 years of experi- 
ence working on devices and inven- 
tions ranging from space devices to 
consumer products. Mike is the presi- 
dent of CM Research, a development 
company that specializes in bringing 
products from concept through proto- 
type to production. You may reach 
him at mzerkus@cmresearch.com. 

John Lusher is an electrical engineer and 
has been involved with USB develop- 
ment for the last two years. You may 
reach him at jlusher@lushertech.com. 

Jonathan Ward is president of Keil 
Software and has been involved in the 
design, implementation, and docu- 
mentation of embedded systems since 
the early 1980s. You may reach him 
via (972) 735-8052. 



RESOURCES 



A glossary of USB terms, a checklist 
for building a USB device, and a list 
of USB suppliers are available on- 
line in Design Forum in May. 



IfToally, Standard RS-485 Nerwarl 

With Cimetrics' 9-Bit U.LAN you can link together up to 250 of the most popular 8- and 
16-bit microcontrollers (8051, 80C196, 80C186EB/EC, 68HC11, 68HC16, 68332, 
PIC16C74). 



The 9-Bit uLAN is: 

► Fast — A high speed (62.5k baud) multidrop 
master/ slave RS-485 network 

► Flexible— Compatible with your 
microcontrollers 

► Reliable— Robust 16-bit CRC and sequence 
number error checking 

► Efficient— Low microcontroller resource 
requirements (uses your chip's built-in serial 
port) 

► Friendly— Simple-to-use C and assembly 
language software libraries, with demonstration 
programs 

► Complete— Includes network software, 
network monitor, and RS-485 hardware 

► Standard— The 9-Bit ulNi is an asynchronous 
adaptation of IEEE 1118 



Mitrotontroller 
or PC Master 




80C186EB/" 




motorola 68HC16 xj 




Cimetrics "^K^ST^ 

TECHNOLOGY Mj^MS^Sf^tSffM^ 

55 Temple Place • Boston, MA 02111-1300 • Ph 617.350.7550 » Fx 617.350.7552 
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LOW COST 

Dominos are rugged, miniature 
encapsulated controllers that com- 
bine lots of analog and digital I/O 
with a fast control-oriented float- 
ing-point BASIC to provide a one- 
stop computation and control solu- 
tion for cost-sensitive control tasks. 
Used stand alone or connected via 
RS-232/RS-485, Dominos are true 
plug-and-gocontrol. 

Domino 1 features: 

• Full floating-point ROMed BASIC 

• 32-KB SRAM and 32-KB EEPROM 

• 1 2 bits of parallel I/O 

• 2 PWM outputs 

• l 2 C bus 

•2-channel 1 2-bit ADC 

• Serial port: 19.2-kbps RS-232A, 
RS-422, or RS-485 

• +5V@ 15mA 

Domino 2 has: 

• all of the above plus 

• 1 6 more bits of high-current parallel I/O 

• Hardware clock/calendar 

• Wide-range power operation 

• Hardware PWM output 

$99 to $139 

Visit our Web site for complete datasheets 

www.micromint.com 

To Order Call: 

1-800-635-3355 

4 Park St - Vernon CT 06066 
860-871-6170 



the GPD. The DLL gets a device handle 
to the device driver in question. 

We want to communicate to the 
first instance of the device driver (i.e., 
the first device to use this driver). If 
we get a valid handle, we can commu- 
nicate to it. Otherwise, the device 



isn't on the bus and the driver isn't 
loaded. We communicate to the driver 
via DevicelOControl. This function 
passes data to and from the device 
driver and it returns success or failure. 

Listing 2 shows how a DLL can be 
used to communicate with the GPD. 




Listing 4— This code shows you an example INF file. 


; F I LE : EXAMPLE. INF 




[Version] 

signature="$CHICAGO$" 
Class=USB 

Provider=%Exanoke£ 
Layout Fi 1 e=LAY0UT .INF 




[Manufacturer] 
XExampl e%=Exampl e 




[PreCopySection] 
HKR,,NoSetupUI,,l 




[Oesti nationDi rs] 
OefaultOestOir=ll 




[LusherFech] 




JUSBWID 06E5&PID 8000 . Devi ceDesc%=FI RMWARE , USBWID 06E5 
%USB\VID_06E58,PID_8001.DeviceDesc%=USBDEV01. USB\VID_06E5 


&PID_8000 
&PID_8001 


[Control Fl ags] 

ExcludeFromSelect=* //removes all devices from device installer list 


[FIRMWARE] 

AddReg=F I RMWARE . AddReg 




[FIRMWARE. AddReg] 

HKR,,DevLoader,,*ntkern 

HKR, ,NTMPDri ver, , f i rmdown . sys 




[USBDEV01] 

AddReg=USBDEV01. AddReg 




[USBDEV01. AddReg] 

HKR, .DevLoader, ,*ntkern 

HKR, .NTMPDriver, .ezusb.sys 




[Strings] 

Example="Example USB" 

USB\VIDJ)6E5&PID_8000.DeviceDesc="USB Firmware Download" 
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ne of USB's 
earliest and most 
important goals was 
▼ to make it easy to use. It 
has to be easy because the computer 
marketplace is rapidly expanding to 
include increasingly less-technical users. 

These users don't know what an 
interrupt or DMA channel is, let alone 
how to finesse them into a working 
configuration. Nor should they have to. 
Even highly technical users are tiring 
of the difficulties involved in config- 
uring or upgrading their computers. 

From my perspective, it's not that 
difficult to install an ISA or PCI card. 
I've been doing this for years and I 
know how to set the jumpers (plug-and- 
play usually takes care of it anyway). I 
rarely get the cables on backwards any- 
more or offset by one row of pins, either. 

But, one part of the process still 
strikes fear into my heart. One part of 
the installation never goes quite the 
way the instructions claim (when I 
finally do get around to reading 
them). There's one element that 
rarely fails to "blue screen" the 
machine repeatedly and strangely: 

THE DRIVER 

I've spent days trying to install 
the drivers for a seemingly simple 
device. Sometimes, it's incompat- 
ibilities with other drivers or soft- 
ware. Sometimes, the driver wasn't 



tested well or has a bug and needs a 
patch or upgrade. Sometimes I never 
do find the problem. 

Wouldn't it be nice if all the driv- 
ers you ever needed came with the OS? 
You'd just plug something in and it 
would work. No more installation 
headaches; no problems moving from 
one machine to the next or even from 
one type of machine to another (e.g., 
from PC to Mac to Linux to worksta- 
tion). There would be reduced disk 
and memory requirements, too, and 
one-stop shopping for upgrades. Over- 
all, compatibility and reliability 
would improve dramatically. 

Developers would find tremendous 
advantages as well, bringing more 
products to more platforms in less 
time and with less effort. Adding USB 
would no longer require the expertise 
(and the time, often in the critical path) 
needed to write drivers. Testing and 
support requirements would be reduced, 
and so would the overall project risk. 

There are thousands of different 
kinds of devices already, and more are 
on the way. An OS can't possibly 
provide all the drivers for all of these 
types of devices. Or can it? 

Although lots of different products 
are or will be available, many of them 
have more similarities than differences. 
In some cases, identical devices are 
produced by different manufacturers. 
In other cases, the products are differ- 
ent but the functions are similar. 

Consider mice, track balls, and 
touchpads. They are physically differ- 
ent (and there's variation even within 
those broad categories), but the overall 
function is the same — moving a cursor 
on the screen. They all provide an x 
and y displacement and two or more 
buttons (or the equivalent). 

What about full-page scanners, 
hand scanners, digital still cameras, 



Host system 



Client software 



USB class driver 



USB host driver K" 



USB host controller K- 



Host system 
Function 



Class layer 



>| 'Standard requesf layer | 



USB interface 



Figure '\-USB uses well-defined protocol layers to reduce 
complexity and improve standardization. 



s Now that we 
J have some 

ZJ of the USB 

basics from Part 1 , 
we're raring to go with 
USB! Jim wonders if 
an OS can provide all 
the drivers for the 
many devices there 
are today. With USB 
classes, he explains, 
it's entirely possible. 
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Figure 2— USB devices use logical "pipes" to transfer 
information. This device uses two. 

and slow-scan video cameras? All 
produce an image of some form. Or 
printers? Color or black-and-white, 
laser or inkjet, Postscript or not — all 
put an image on paper. 

With a little insight and forethought, 
most devices can be grouped into fewer 
categories, each with a common pur- 
pose and set of requirements. Then, it's 
possible to define a common API for 
each category and therefore the re- 
quirements of a single, generic driver 
suitable for use with any of the de- 
vices in that group. USB is trying to 
accomplish exactly this by defining a 
variety of device classes. 

The USB specification defines the 
mechanical and electrical requirements 
for all USB .devices as well as the fun- 
damental protocols and mechanisms 
v ' to configure the device and trans- 
port data. The class definitions are 
add-on documents that refine the basic 
mechanisms and use them to establish 
the class-specific blueprint for both 
the device and the generic driver. 

There will always be unique devices 
as well as manufacturers that choose 
to differentiate their product from the 
competition within the driver. For 
these cases, vendor-specific drivers 
will always be necessary. 

But for most products, it'll be pos- 
sible to use generic drivers that are part 
of (or included with) the OS. That's 
one of the most important advantages 
of USB. 

Comm, Printer, Image, Mass Stor- 
age, Audio, and HID (human interface 
device) are a few of the defined USB 
classes. Some devices may fit into 
more than one category. 

For example, there are combination 
printers/scanners. Although physically 
this is one device, logically it is two. 
^art of the device fits into the Printer 
xass and uses that generic driver. Part 
of it fits into the Image class and uses 
that driver. Devices in more than one 
class are called compound devices. 



DEVICE CLASSES 

Windows 98 includes many but not 
all of the USB class drivers. This situ- 
ation is unfortunate, but it couldn't be 
helped because some of the class defi- 
nitions weren't finished in time (some 
still aren't complete). 

Future releases and service packs 
will add additional class drivers until 
most or all of them are available and 
supported. Apple and Sun Microsystems 
also have class driver implementations 
available or underway for their respec- 
tive platforms. 

As the name implies, HIDs are 
designed for some kind of human input 
or output. The most common examples 
are keyboards, pointer devices like mice, 
and game controller devices such as 
joysticks and gamepads. 

This class also includes things like 
front panels or keypads (e.g., on a tele- 
phone or a VCR remote control), dis- 
play panels or lights, as well as tactile 
and audible feedback mechanisms — 
essentially, anything you might press, 
twist, step on, measure, move, read, 
feel, or even hear. 

Seemingly, this class would include 
almost anything connected to a com- 
puter, but it doesn't. Its primary pur- 
pose is control. Although it's very 
flexible, this class definition doesn't 
handle large amounts of data well. It 
doesn't need to ; other device classes 
can better serve that purpose. 

In a USB speaker, for example, the 
volume, tone, and other controls fall 
well within the HID class. But, the 
sound channels are data intensive, so 
they are better handled by the Audio 
class. In fact, many products in the 
other classes are compound devices 
with HID handling the controls. 

Given the diversity of USB applica- 
tions in general and HID devices in 
particular, how can any one driver hope 
to do all the things required by its class? 
The first part of the answer comes 
from the physical interface. There's 
only one! All USB devices communi- 
cate with the host via their USB port. 

This sounds self-evident, but the 
implications are tremendous. The USB 
port works according to the same 
basic principles for all devices, in all 
modes of operation. The class driver 
never needs to worry or know about 



ISA or PCI buses, SCSI, IDE, or AT API 
interfaces, serial ports, parallel ports, 
keyboard ports, mouse ports, game 
ports, or anything else for that matter. 

The class driver doesn't even need 
to know much about USB ports. Even 
that physical interface is abstracted 
and managed by the USB Host driver. 
This abstraction, or layering, is another 
key concept that makes class drivers 
possible. 

Each layer has its own responsibili- 
ties and it uses APIs provided by the 
lower levels to accomplish them. It 
doesn't need to know how the lower 
levels work or which ones are present. 

Figure 1 shows a simplified view of 
the various protocol layers that might 
be present for a USB device. Note that 
there are connections at all levels, but 
most of these are logical. 

The single physical connection is 
between the USB host controller and 
the device's USB interface and is at the 
lowest level (shown in black). This 
layer is the hardware — the cables, 
connectors, and state machines. 

The first layer of software, which 
is required in all cases (in light blue), is 
the USB host driver on the computer. 
On the USB device it is the essential 
firmware that manages the hardware 
and provides the standard requests 
(also called "chapter 9" requests be- 
cause they are in that chapter of the 
specification). There's a logical connec- 
tion between these layers for configur- 
ing and controlling the USB interface. 

The device driver layer comes next 
(shown in grey) and is usually the class 
driver(s) on the host side and the cor- 
responding firmware on the device side. 
The logical connection at this level 
carries class-specific commands and 
requests, although these often use 
protocols modeled after those in the 
layer below. 



ByteO: 


<raserved> data 


Byte 1: 


Xdata 


Byte 2: 


Ydata 


Byte 3: 


Buttons 


padding 



Figure 3— This sample report for a USB joystick shows 
you one possible data organization. 
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Figure 4— This schematic shows you a typical connection between 
the USBN9602 and the USB connector (or cable). 



The top (dark blue) layer is the one 
the user sees and cares about. For ex- 
ample, the client software on the host 
might be a flight simulator and the 
associated function might be a joystick. 
At this layer, the only thing the client 
software (and user) cares about are the 
joystick inputs. It doesn't care (and 
doesn't need to know) how those inputs 
are read, packaged, and transported. 

PROTOCOL LAYERS 

To communicate with a USB device, 
the host software opens up a series of 
pipes, and uses them to transport data. 
The pipes correspond to hardware end- 
points, which are individual channels, 
usually with dedicated buffers or FIFOs. 

Pure HID devices use only two 
pipes (see Figure 2). The control (default) 
pipe, required by all USB devices, is 
used for receiving and responding to 
specific requests or commands. The 
standard requests use this pipe, and 
many of the class definitions (includ- 
ing HID) add class-specific requests. 

The interrupt pipe sends asynchro- 
nous data to the host. This pipe is 
poorly named; USB doesn't support 
true interrupts but rather enables the 
device to predefine a maximum poll 
interval. This way, if a key is pressed, 
the mouse moved, or the joystick 
steered, the device can report in a 
timely fashion without a specific 
request (from the driver) to do so. 

The HID class driver starts with 
the physical/standard request API 
common to all USB devices and adds 
the HID standard pipe structure and 
command superset. The difference 
from one HID device to another is the 
data it returns and what the data means. 

HID data is packaged into structures 
called reports. Figure 3 shows a s 



report for a joystick. It's simple 
and composed of four bytes. 

The first byte is unused here 
but is reserved for a throttle 
position on another model. 
The second and third bytes are 
the x and y coordinates, respec- 
tively. The fourth byte contains 
information about the four 
buttons (one button per bit, 
with four unused bits that are 
zero-filled to pad out the byte). 
This is just one example 
for one joystick. Other HID devices 
have different report structures. Other 
joysticks may have other structures, 
too. Some may order the data differently 
or have additional functions and capa- 
bilities (e.g., force-feedback). 



SAMPLE REPORT 

Obviously, the HID class driver 
can't keep report maps for all possible 
implementations of all possible devices. 
The device has to be able to describe 
the report to the class driver. This too 



is in keeping with standard USB 
mechanisms. 

USB devices use predefined data 
structures called descriptors to describe 
their identification, capabilities, re- 
quirements, and protocols. The USB 
spec defines device and configuration 
descriptors that must be provided by 
all devices. The HID class definition 
adds information to these and goes on 
to define a report descriptor. 

The report descriptor provides the 
map that the HID class driver needs 
to understand and interpret the report. 
The structure of the report descriptor 
is complex, though flexible. Fortunately, 
it doesn't complicate the device-side 
firmware because it is a data structure 
that can be written and compiled 
externally and then remain constant. 

Listing 1 shows a sample report 
descriptor. The details are beyond the 
scope of this article, but note that it 
defines the type of application, size, 
maximum and minimum values, and 
subtypes of the various report fields. 



Listing 1— This ReportDescri ptor function corresponds to Figure 1. USB devices use descriptors 
to describe themselves to the host PC. 



unsigned char 


ReportDescri ptor[59] = { 




0x05, 


0x01, 


/* 


USAGE_PAGE (Generic Desktop) 


*/ 


0x15, 


0x00, 


/* 


L0GICAL_MINIMUM (0) 


*/ 


0x09, 


0x04, 


/* 


USAGE (Joystick) 


*/ 


Oxal, 


0x01, 


/* 


COLLECTION (Application) 


*/ 


0x15, 


0x00, 


/* 


LOGICAL MINIMUM (0) 


*/ 


0x26, 


Oxff , 


0x00, /* 


LOGICAL MAXIMUM (255) 


*/ 


0x75, 


0x08, 


/* 


REPORT SIZE (8) 


*/ 


0x95, 


0x01, 


/* 


REPORT COUNT (1) 


*/ 


0x81, 


0x03, 


/* 


INPUT (Cnst,Var,Abs) 


*/ 


0x05, 


0x01, 


/* 


USAGE_PAGE (Generic Desktop) 


*/ 


0x09, 


0x01, 


/* 


USAGE (Pointer) 


*/ 


Oxal, 


0x00, 


/* 


COLLECTION (Physical ) 


*/ 


0x09, 


0x30, 


/* 


USAGE (X) 


*/ 


0x09, 


0x31, 


/* 


USAGE (Y) 


*/ 


0x95, 


0x02, 


/* 


REP0RT_C0UNT (2) 


*/ 


0x81, 


.0x02, 


/* 


INPUT (Data ,Var,Abs) 


*/ 


OxcO, 




/* 


END_C0LLECTI0N 


*/ 


0x15, 


0x00, 


/* 


L0GICAL_MINIMUM (0) 


*/ 


0x25, 


0x01, 


/* 


LOGICAL MAXIMUM (1) 


*/ 


0x75, 


0x01, 


/* 


REPORT SIZE (1) 


*/ 


0x95, 


0x04, 


/* 


REPORT COUNT (4) 


*/ 


0x81, 


0x03, 


/* 


INPUT (Cnst,Var,Abs) 


*/ 


0x05, 


0x09, 


/* 


USAGE_PAGE (Button) 


*/ 


0x19, 


0x01, 


/* 


USAGE_MINIMUM (Button 1) 


*/ 


0x29, 


0x04, 


/* 


USAGE MAXIMUM (Button 4) 


*/ 


0x55, 


0x00, 


/* 


UNIT_EXP0NENT (0) 


*/ 


0x65, 


0x00, 


/* 


UNIT (None) 


*/ 


0x95, 


0x04, 


/* 


REP0RT_C0UNT (4) 


*/ 


0x81, 


0x02, 


/* 


INPUT (Data,Var,Abs) 


*/ 


OxcO 




/* 


END COLLECTION 


*/ 
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Figure 5— This schematic shows a serial interlace between the USBN9602 and a COP8 microcontroller. It also shows the oscillator circuit, b— Here's another serial interface. In 
this case, the microcontroller is a 68HC11. c-ln this parallel interlace to the USBN9602, the microcontroller is an Intel 80C188EB. But, this example would be typical of any 
case where an 8-bit data bus is available. 



So, a class-compliant USB product 
can entirely specify what it is and how 
it works in the onboard firmware. This 
makes the job of building, testing, and 
modifying a USB interface easier and 
more modular, and it brings it within 
the capabilities of most developers. 

In the joystick, there are only three 
essential blocks — the ADC, USB inter- 
face, and microcontroller. The micro 
ties it all together, sampling the joy- 
stick at intervals and passing the data 
up through the USB interface (also 
managed by the micro). 

The only new element is the USB 
interface. There are many varieties 
available: some are integrated with the 
microcontroller and some are separate 
components. These interfaces contain 
the state machines and buffers necessary 
to transmit and receive serial data on 
the USB. Conceptually, it's a smarter- 
than-average UART-like function. 

National Semiconductor's USBN- 
9602 is one example of a USB inter- 
face. One side is attached to the USB 
cable or connector with a circuit like 
the one in Figure 4. (This figure and 
the ones following are not complete 
schematics; they merely highlight 
specific functions and interfaces.) 

C3 and C4 bypass the USBN9602's 
internal voltage regulator (used by the 
internal USB transceiver). Rl is the 
required pullup that the device uses to 
signal its presence (and data rate) on 
the bus. The other components reduce 
EMI and transmission line effects to 
provide a cleaner signaling environment. 



TYPICAL CONNECTIONS 

The other side of the USBN9602 is 
the data path to the microcontroller. 
This data path is flexible and allows 
easy use with a variety of serial or 
parallel interfaces (there's even a 
DMA interface for high data rates). 

Figure 5a shows a Microwire inter- 
face to a COP8 microcontroller, as well 
as the requisite dot clock oscillator 
circuit. Figure 5b shows an SPI interface 
to a 68HC11, and Figure 5c shows a 
parallel interface to an 80C188EB. 

To make it even easier, several USB 
device manufacturers provide sample 
firmware source code. For the USBN- 
9602, National provides source code 
in C with compiler options for all of 
the microcontrollers mentioned here 
(and readily ported to others). This 
code is available on the web. Such 
firmware provides a ready-made solu- 
tion to the some or all of the necessary 
device-side protocol layers. 

If you want to build a mouse, key- 
board, or other FDD device, just modify 
the descriptor tables and a few top-level 
(function and class layer) firmware 
routines. Even if you're not building 
an HID device, the firmware layer 
that manages the USB interface device 
and responds to the standard requests 
provides a solid basis to start with. 

PLAIN AND SIMPLE 

USB simplifies the lives of developers 
and experimenters alike. It's possible 
for OSs like Windows 98 to provide 
most of the drivers you'll ever need 



for USB devices via class drivers, which 
make USB easier to incorporate into 
products and embedded systems. S 

Jim Lyle is a staff applications engineer 
at National Semiconductor where he 
has worked with flash memory, micro- 
controllers, and USB products. Jim has 
also worked as a development engineer 
and technical marketing engineer for 
Tandem Computers, Sun Microsystems, 
and Troubador Technologies. You may 
reach him at jim.lyle@nsc.com. 



RESOURCES 



USB information, www.usb.org 
HID device information, www.usb. 
org/developers/hidpage.htm and 
www.microsoft.com/hwdev/hid 
USBN9602 firmware source code, 
www.national.com/sw/USB 



SOURCES 



USBN9602, COP8 

National Semiconductor 
(408) 721-5000 
Fax: (408) 739-9803 
www.national.com 

68HC11 

Motorola 
(512) 895-2649 
Fax: (512) 895-1902 
www.mcu.motsps.com 

80C188EB 

Intel Corp. 
(602) 554-8080 
Fax: (602) 554-7436 
www.intel.com 



72 Issue 107 June 1999 



CIRCUIT CELLAR* 



www.circuitcellar.con) 



MICRO 
SERIES 



Glen Reuschling 



USB Primer 

Low-Speed USB Host Controller 



lmost two years 
ago, I read a trade- 
publication announce- 
ment for a new 8-bit USB 
microcontroller from Cypress Semi- 
conductor. Coming from a background 
in PID and PLC controllers, I immedi- 
ately saw the potential for such a chip. 

At $1 apiece, you could create fami- 
lies of USB-smart motors, sensors, and 
actuators, all plugged into a USB-based 
microcontroller. Imagine not having to 
worry whether a thermocouple is J, K, 
or T type because the calibration and 
correction factors are already taken 
care of by the USB microcontroller. 

A standard digital interface elimi- 
nates the need to configure special 
inputs and outputs before shipment to 
a particular customer. The tiered star 
arrangement of the USB interface lends 
itself nicely to the wiring structure of 
many industrial machines and elimi- 
nates the rat's nest of wires that con- 
verges at the back of an embedded 
multiloop controller. 

The resulting collection of USB 
smart peripherals forms a simple dis- 
tributed processing network, a poten- 
tially useful feature. The hot-swap 
and plug-and-play features of the USB 
offer the possibility of being able to do 
service and maintenance on a machine 
without costly shutdowns. 

Not only does a digital signal path 
offer tremendous noise immunity 



over millivolt-level analog signals in 
the industrial environment, but it also 
allows for the use of optoisolators for 
electrical isolation — a must in an 
environment where 220 and 440 VAC 
are standard working voltages. 

Finally, the ability to put a USB 
microcontroller to sleep means low 
power consumption for those situa- 
tions where that's a consideration. 
With all of this in mind, I ordered the 
Cypress USB Development Kit ("USB 
Micro," Circuit Cellar 88). 

When it arrived, I fired it up, wrote, 
downloaded, and ran a few simple 
programs, but that was it. My older 
workbench computer doesn't have 
USB ports, nor were there any USB 
interface plug-in cards available. 

On top of that, the only USB soft- 
ware driver available was a beta version 
for Windows 95. All my development 
software is DOS- and Windows 3.1- 
based, and I wasn't ready to buy a new 
Pentium motherboard with USB sup- 
port for my workbench and then install 
Windows 95 on it. 

Not to be deterred, I looked into 
the availability of a chip or chipset 
that I could use to implement a USB 
host controller. The few I could find 
were all targeted to the PCI bus. None 
were targeted to the embedded micro- 
controller market. 

I checked into the possibility of 
obtaining a USB host controller as 
intellectual property in HDL format, 
but price tags were five and six figures 
in size. Another dead end. 

After downloading and reviewing 
the Universal Serial Bus Specification, 
Rev. 1 .0, it was apparent that the low- 
speed USB specifications were a some- 
what reduced and doable subset of the 
full-speed USB specifications. At this 
point, I decided that I could and would 
build my own low-speed USB host 
controller from scratch. 

Eight months and many dead ends 
later, I finally put together the four- 
port USB host controller shown in 
Photo 1, tied it to an 8051 -type micro- 
controller, and got it to talk to the 
CY7C3650 USB development card. So, 
what started out as a personal challenge 
to build my own USB host controller 
from scratch turned into a comprehen- 
sive USB learning experience. 



To wrap u[ 
our series 
on the 
Universal Serial Bus, 
Glen presents a two- 
part discussion on 
building USB hard- 
ware from scratch. 
This month, he lays 
the groundwork for 
putting together a 
USB host controller. 
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This article recounts the work I did 
in building my low-speed USB host 
controller. By describing the problems 
I encountered and the solutions I came 
/vith, my goal is to fill in the gaps 
in the standard USB documentation 
and make the USB more accessible. 

This article is not a comprehensive 
review of the USB. I assume you're 
already familiar with the basics of the 
USB operation. For those of you who 
need to brush up on it, there are many 
good introductory articles to be found 
in various hardware-oriented publica- 
tions, starting with Parts 1 and 2 of 
this Circuit Cellar MicroSeries. 

Other excellent sources of informa- 
tion on the USB interface can be found 
in the datasheets and application notes 
published by the various chip manu- 
facturers that offer USB products. A 
good example is Anchor Chips' web 
site, where a number of documents 
are posted that contain a wealth of 
tutorial-level information. 

HOST CONTROLLER'S ROLE 

Within the USB operation, the host 
controller has a distinguished role in 

^ntrast to those devices that are 
-oferred to as USB microcontrollers. 
The USB is a half-duplex serial bus 
with only one bus master (i.e., the 

host controller), but all of 

the USB microcontrollers 
that are commercially avail- 
able are (by design) bus 
slaves and cannot perform 
the host-controller functions. 

The advantage of the 
USB is that by offering a 
single standard interface for 
all low- and medium-speed 
peripherals, it eliminates 
the hassles of installation 
and configuration. It also 
offers true plug-and-play 
and hot-swap capabilities — 
features which, until now, 
have not been generally 
available to desktop PC 
users. 

Although tunneling all 
the different peripheral 
device communications 
through a single interface 
may make life easy for the 
PC user, it poses a major 



challenge to the hardware and software 
developer. The problem with this ar- 
rangement is that a single interface 
must now do the work of all the vari- 
ous plug-in cards and software device 
drivers that currently reside in the 
desktop PC. 

Now, all the functions that could 
previously be spread out over a num- 
ber of pieces of hardware and software 
must all be incorporated into a single 
combined hardware/software interface — 
the host controller. 

To deal with the range of demands 
that the different kinds peripheral 
devices put on the USB interface, the 
USB Specification calls for four differ- 
ent modes of data transfer (control, 
interrupt, isochronous, and bulk trans- 
actions) and two different bus speeds 
(full and low speeds with data rates of 
12 and 1.5 MBps, respectively). 

Applications pass data through the 
USB by supplying the host controller 
with pointers to memory locations 
where data is to be moved from or to. 
In turn, the host controller keeps track 
of everything by using linked lists of 
linked lists of these pointers. 

It is this complexity of the host- 
controller function (i.e., its need for 
fast memory bus access and a fast 
CPU to handle the computational 
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Photo 1 — This is it: the final version of my host controller project The pan's along the 
top and left of the photo include a standard 8051-type microcontroller, and the parts 
filling in the bottom right form the pSIE. 



overhead of each peripheral's associ- 
ated device driver) that have restricted 
the commercially available full-speed 
USB host controllers to machines 
with either a PCI or other fast Local 
bus and OSs like Windows 98. 

FULL SPEED VS. LOW SPEED 

The full-speed USB protocol supports 
all four modes of data transfer with a 
maximum bandwidth of 1.5 MBps and 
a maximum data payload per transfer 
of 1023 bytes per packet per 1-ms frame 
for isochronous transactions [1, p. 55]. 

The host controller is required to 
prioritize and schedule all individual 
transfers, track the timing on isochro- 
nous transactions, and do error check- 
ing for bulk transactions. That's why 
full-speed USB host controller functions 
will always be beyond the capacity of 
the small embedded microcontroller. 

On the other hand, low-speed USB 
supports only control and interrupt 
transactions, the two modes that entail 
the least computational overhead. 
Although the theoretical maximum 
bandwidth for low-speed transactions 
is 187.5 KBps, the maximum packet 
size per transaction is eight bytes. 

This fact, combined with the maxi- 
mum bus-access frequency per device 
of once every 10 frames, translates to 

a maximum data payload of 

only 800 Bps per low-speed 
endpoint channel (i.e., a 
doable data rate, even for a 
small 8-bit micro) [1, p. 57]. 

If you intend to interface 
exclusively to low-speed 
USB devices, a USB host 
controller becomes a possi- 
bility for small embedded 
micros. The requirements 
to support low-speed host 
controller functions are 
well within the capabilities 
of any fast 8-bit controller. 

Regarding low-speed data 
rates, the bus access rate of 
once every 10 frames is a 
specification, not a hardware 
limit. It may be possible 
(depending on the low-speed 
device being used) to exceed 
this 800-Bps data rate by 
accessing it more often than 
once every 10 frames. 
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Figure 1 — These are the basic functional building blocks that compose my low-speed host controller's uSIE. 



A second way to multiply data rates 
to an USB device is to access multiple 
endpoints within a single device. How- 
ever, low-speed devices are limited to 
only two endpoints besides the default 
endpoint [1, p. 47]. 

On the mechanical side, full-speed 
USB specifies a shielded twisted-pair 
cable for the signal lines, but for low 
speed, neither twisted pair nor shield- 
ing is specified [1, p. 86). Maximum 
specified lengths are 5 m for full-speed 
and 3 m for low-speed cables [1, p. 89]. 

But, for practical purposes, signal 
integrity and the bus turnaround time 
set the upper usable length limits. So, 
despite the specifications, with proper 
cable selection, you should be able to 
wire a house-sized area with low-speed 
USB peripherals. 

No doubt you've already encoun- 
tered the term serial interface engine 
(SIE). The SIE is to the USB what the 
UART is to the RS-232 interface. The 
only functional difference between the 
two (from the processor's point of view) 
is that a UART passes data on a FIFO 
buffer (possibly only one byte deep), 
while the SIE passes data directly to 
and from the processor's memory via 
pointers. 

For the sake of discussion, I'll use 
the term "micro serial interface en- 
gine" (uSIE) to refer to the minimum 
hardware necessary to implement 
completely and correctly all low-speed 
USB host-controller functions. Inter- 
estingly enough, the uSIE hardware 
requirements for the host controller 
are less than those for a USB slave SIE. 

Because the USB protocol encom- 
passes both hardware and software 



issues, it makes sense that a host con- 
troller is partly hardware and partly 
software in its makeup. For this rea- 
son, there are many different ways to 
build a host controller, depending on 
which functions are implemented in 
hardware and which ones are imple- 
mented in software. 

HARDWARE INTRODUCTION 

The first step in building a USB 
host controller is to visit the USB 
Implementers Forum web page and 
download: 

• "Universal Serial Bus Specification," 
Rev. 1 .0 and the white papers 

• "Cyclic Redundancy Checks in USB" 

• "Designing a Robust USB Serial 
Interface Engine (SIE)" 

For a membership fee of $2500 per 
year, you can join the USB Imple- 
menters Forum and have extended 
access to documents and tech support. 
But, this membership fee is out of the 
range of a lot of people, including me. 

If you choose to download and read 
the USB Specification, two notes of 
warning are in order. First, the full 
USB specifications encompass issues 
of software, hardware, and communi- 
cations protocol. 

Unfortunately, the authors of the 
document use the same words at dif- 
ferent points to reference alternately 
hardware, software, and communica- 
tions protocol issues. Although this 
overloading of definitions may not 
bother a C++ programmer, it blurs the 
lines between the different aspects of 
the USB specifications and makes 
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them confusing to read from a hard- 
ware builder's point of view. 

Second, the USB Specification is 
D' <md was never written to be a 
s, ematic guide for building USB 
hardware. With patience, most of the 
information you need to guide you in 
building a USB interface can be found 
in the USB Specification. As for de- 
tails not explicitly stated in the Speci- 
fication, be prepared to resort to some 
trial and error work to find them. 

To help you locate information 
within the USB Specification and 
elsewhere, I included a list of refer- 
ences that source specific page num- 
bers and sections. 

HOST CONTROLLER HARDWARE 

Figure 1 shows the minimum hard- 
ware configuration necessary to imple- 
ment a USB host controller. A short 
guided tour of this basic uSIE starts 
with the output section, which is the 
easiest to implement. 

USB uses 8-bit bytes as its basic unit 
of data. So, as in all serial interfaces, 
the signal path begins with a parallel 
to serial conversion. Data is loaded 

byte at a time and shifted out 
starting with the least significant bit. 

The next step in the signal path is 
encoding and modulation, which in- 
cludes bit stuffing and NRZI encoding 
[1, pp. 121-122). Extra bits are added 
to the signal stream to ensure ad- 
equate transitions for syncing and 
clock separation. Then, data informa- 
tion is encoded as a differential signal 
and control information is encoded as 
DC level signals [1, p. 115]. 

The serial signal stream is then 
passed to the output buffer section. 
This section is responsible for line 
driving, slew rate control, hot-swap 
power management functions, and 
low- and full-speed device detect. 

The return signal path becomes 
more complicated. Because there's no 
separate clock line in the USB, the 
receive clock must be derived from 
the incoming signal. This function is 
performed by a digital phase lock loop 
(DPLL) [2, p. 2). 

DC level control signals must be 
etected, bus time-out intervals must 
be monitored, and this information 
passed on to the control section of the 

www.circuitcellar.com 



uSIE. Once it is past this input i 
the return serial signal path is just the 
reverse of the outgoing path. 

To avoid using memory pointers, 
the uSIE uses a dual-port RAM as the 
processor/uSIE interface. Rather than 
passing pointers, the microcontroller's 
software is responsible for placing data 
to be sent or received only at specific 
memory locations. This is an example 
of a hardware/software tradeoff you can 
make when building a host controller. 

Although the control logic is shown 
as a small block in Figure 1, it repre- 
sents a major portion of the uSIE. Also, 
not shown is the 1 -ms frame clock and 
the functions of CRC generation and 
checking that can be implemented 
quite easily in software by the micro- 
controller. 

JUST GETTING STARTED 

Now you've got a USB background 
and some resources to check out for 
more information. Next month, I'll 
introduce my low-speed USB host 
controller and the lessons I learned 
while putting it all together. My goal 
is to show you that there's no reason 
USB should remain only the province 
of desktop PCs. A 

Glen Reuschling is a manufacturing 
engineer by day and a serious hobby- 
ist by night. His most recent home 
project resulted in this article. You may 
reach him at wildiris@cruzio.com. 
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Building a USB Host Controller 



ast month, I 
introduced my 
host controller. Now, 
I want to show you how 
it all came together. 

First, a note on the choice of parts 
that went into it. I chose the TT TUSB- 
2040 four-port USB HUB for the core 
of the uSIE because it's a stand-alone 
part that requires no programming 
and is available in a DIP package. 

HUB support chips were chosen 
based on the application examples in 
the TUSB2040 datasheet. CPLDs, which 
support in-circuit programmability, 



are a must for the initial 
of your host controller. 

As we go through the process, you 
may want to have these files (available 
on the Circuit Cellar web site) handy: 

• HUB01C.PLD — programming for low- 
and full-speed clock generation, the 
DPLL, and bus time-out detect logic 

• HUB04C.PLD— dual-port RAM address 
control logic 

• HUB02C.PLD— uSIE functions 

To make signal tracing easier, the net 
names used in Figures 1 and 2 match the 
variable names used in the . PLD files. 

A simple way to implement sub- 
routines within state-machine logic is 
to use a multiphase clock. One level 
of state machine controls the clock 
signals to the next level down. 



The top-level state machine con- 
trols the idle, start of frame, and send/ 
receive states. At the next level down 
are the state machines that generate 
send and receive transactions. The third 
and fourth levels are responsible for 
bit and byte manipulation. 

Although the complete uSIE (in- 
cluding the dual-port RAM) can be put 
into a single, large CPLD, it's less 
expensive to implement a design us- 
ing several smaller devices. But al- 
ways pick a bigger part than you think 
you need. To help debugging, leave a 
few extra pins on your CPLD for test 
points. 

GETTING STARTED 

Start with a development card or 
prototyping system for your favorite 
8-/ 16-bit microcontroller. A debugger 
for downloading and running code is 
essential. And be prepared to generate 
a number of different test routines. 

Set aside some memory space for a 
dual-port RAM; 1 or 2 KB is enough. 
This RAM will be the main driving 
engine for your host controller. A good 
storage oscilloscope or logic analyzer is 
a must for debugging the hardware. 

CLOCKING THE pSIE 

Several system clock signals must be 
generated for the pSIE [3]: a four-phase 
full-speed 12-MHz clock, a four-phase 
1.5-MHz low-speed clock, and the 
1-ms frame period clock. The uSIE uses 
a 48-MHz crystal oscillator as the 
primary source for all timing, so gen- 
erating the 12- and 1.5-MHz four-phase 
clock signals becomes straightforward. 

The USB Specifications call for the 
1-ms frame clock to be adjustable [1, 
p. 124], but this is from the perspective 
of a USB slave device. Many USB slave 
devices use ceramic resonators instead 
of crystals for their clock so some 
provision was included to compensate 
for their lower accuracy and stability. 

The 1-ms frame clock is imple- 
mented as a divide-by-n counter, with 
n giving the adjustability called for [4]. 
Because the host controller is the bus 
master and sets the 1-ms frame period, 
it doesn't need to be software adjust- 
able. So n is fixed equal to 48,000. 

Regarding the 1-ms frame clock as 
implemented in HUB01C.PLD, the 
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have no excuses left: 
USB is a mystery no 
longer. By describing 
the step-by-step con- 
struction of his low- 
speed USB host con- 
troller, Glen reveals 
the inner workings of 
USB hardware. 
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: switching the CPLD does, the 
more power it dissipates. At 48 MHz, 
the Lattice part gets quite warm, so the 
divide-by-n counter was broken up into 
several stages, each being clocked by a 
slower signal from the stage before. 

FEEDING THE mSIE BABY 

The first test routine to run on your 
8-/ 16-bit micro is one that, upon a 
hardware interrupt generated by the 
host's 1-ms frame clock, writes a few 
bytes of data out to a starting location 
in the dual-port RAM. Make the first 
byte (i.e., ByteCount) the number of 
bytes in your test packet. 

The first HDL state machine to 
download to the CPLD is one that, 
when initiated by the 1-ms frame 
clock, starts by reading the number of 
bytes to transfer and loads the data se- 
quentially from the dual-port RAM into 
a shift register [5] and clocks it out as a 
serial stream. Output clocking is a shift- 
right least-significant-bit-first operation. 

Exactly how the data is read from 
or written to the dual-port RAM de- 
pends on what stage of the build-and- 
test process you're at. Understanding 
the final form of the dual-port RAM's 
read/write logic must wait until after 
the inner workings of the pSIE have 
been explained. 



Using the serial bitstream generated 
by the first test routine, start imple- 
menting in HDL code the bit-stuffing 
and NRZI-encoding functions [1, pp. 
121-122]. Bit stuffing is accomplished 
by counting the number of Is (in a row) 
sent and, when that count hits six, 
clocking a into the NRZI encoding 
section without clocking the serial- 
out shift register [6]. 

USB is a two-wire medium, so there 
can be up to four signal states. Data 
information is encoded as a differential 
signal; control information is encoded 
as a DC-level signal [1, p.115]. 

The USB uses three of the four pos- 
sible states — J logic state, K logic states, 
and the single-ended zero (SEO) state 
used for sending control information 
[7]. Also, the NRZI state machine needs 
a disconnect or floating-output state. 

The Sync Pattern determines the 
initial state and initial transition for the 
NRZI state machine. When the host 
controller initiates a transaction, it 
takes the bus from a floating state to 
the Idle state. 

The first Sync Pattern transition is 
from Idle to K. So, the NRZI state ma- 
chine must start in the disconnect state, 
go to the J state for one bus-clock period, 
then transition to the K state. After this 
startup, the NRZI encoder runs itself. 




Figure 1— This schematic shows the wiring diagram lor the TUSB2040 four-port USB hub. The TUSB2040 is a +3.3-V 
device, so a butler (U14) was included to translate between +3.3- and +5-V logic levels. 
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In NRZI encoding, data is encoded 
as transitions, not levels. A gives a 
transition,- no transition indicates a 1. 
When viewing the USB signal on your 
logic analyzer, don't look at it as a 
sequence of Is and Os. The transitions 
between Is and Os represent the bits 
in the USB serial signal. 



DIFFERENTIAL LOGIC LEVELS 

The differential logic levels for low- 
speed USB communication are the 
reverse of those of the full speed, but 
the SEO control signal is still the same. 
Reversing prevents full-speed devices 
from responding to low-speed signals. 

But, this reversing is only from the 
perspective of the slave controller. The 
host still sends out all transactions in 
full-speed differential logic levels. 

The last hub device before the 
receiving low-speed device is respon- 
sible for reversing the sense of the 
differential signal levels [1, p. 224]. 
So, the uSIE doesn't need to imple- 
ment or support the full-/low-speed 
signal-level reversal. 

Now that your prototype host con- 
troller can generate a serial bitstream 
of the right form, issues of USB proto- 
col must be dealt with (i.e., what bytes 
of data and in what order must they 
be written to the dual-port RAM). 

Due to definition overload, 
the information in chapter 8 of 
the USB Specification, "Proto- 
col Layer," can be difficult to 
interpret. Unfortunately, this 
chapter is essential for USB 
hardware design. 

Figure 3, which shows a Start 
Of Frame (SOF) packet and a 
complete USB hub Control Read 
sequence, may help elucidate 
the hardware-level details of the 
USB transaction protocol. It's 
an expanded version of the Con- 
trol Read sequence in Figures 8- 
12 of the Specification [1, p. 154], 

The Control Read sequence 
shown here is the GET DESCRIP- 
TOR device request. Because the 
USB uses the duration of the SEO 
state to encode control signals, 
time-delay information is critical. 

The next USB test signal the 
host controller needs to generate 
is the SOF packet [1, p. 149]. So, 
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the second test routine to download and 
run on your 8 -/16-bit controller is one 
that, upon a hardware interrupt gener- 
ated by the host's 1 -ms frame clock, 
increments an 11 -bit frame counter, 
constructs the next SOF packet, and 
writes that packet to your starting 
location in the dual-port RAM. 

I let the microcontroller generate 
all data fields and the uSIE generate all 
control signals. My controller does Sync 
Pattern, PID, Frame Count, CRC5, 
CRC16, and ACK ; the uSIE generates 
the Idle and End of Packet (EOP) states. 

Sync Pattern is seven Os followed by 
a 1 — that is, the byte 80h shifts out least 
significant bit first [1, p. 123]. When 
this byte is run through bit stuffing and 
NRZI encoding, it becomes [Floating, 
Idle,K,J,K,J,K,J,K,K] in USB form or 
(HiZ,l,0,l,0,l,0,l,0,0) as logic levels. 

The 5-bit CRC is easily generated via 
a 2-KB look-up table, with the 11 -bit 
frame count as the address offset [8]. 

In addition to the bytes fed to it via 
the dual-port RAM, the host needs to 
append the final EOP and Idle control 
states. The EOP is a SEO state, and the 
Idle is a J state. After these are sent, the 
USB signal lines are floated in antici- 
pation of a possible return signal. 

The EOP and Idle control states are 
specified as time durations, which are 
different for low and full speeds [1, p. 
125]. It's easier to think of them in 
terms of bus clock periods, the EOP 
being two and the Idle state being one 
bus clock period, respectively. 

For USB, the word "transaction" 
refers to the process of data transfer 
between the host controller and the 
slave USB device. It's not a hardware- 
level concept but a protocol- or software- 
level concept. At the hardware level, the 
basic communication unit is the packet. 

A transaction consists of a sequence 
of packets (initiated by the host| being 
sent back and forth between the host 
controller and a USB slave device. The 
host's uSIE sends and receives individual 
packets. Completing a full transaction 
is a software issue for the 8-/ 16-bit 
microcontroller. 

The USB Specification calls for ten 
different packet types, each one being 
identified by its PID and representing 
a different handshake message or data 
message type [1, p. 146]. A USB trans- 



action starts with the host controller 
sending a Token packet, or, in the case 
of low-speed transactions, a Special 
packet followed by the Token packet. 

The Token packet initiates commu- 
nications, but after the initial Token 
packet is sent, there may or may not 
be any further packets sent or received. 
For example, the SOF transaction con- 
sists of only the SOF Token packet. 

Here's a classic example of the defini- 
tion overloading that makes reading 
the USB specification difficult for the 
uninitiated. Depending on the context, 
"SOF" can refer to a transaction type, 
a packet type, or a Token PID. 

Building the SOF packet starts with 
the microcontroller placing the Byte- 
Count byte, then the sync byte, the PID 
byte, and two bytes for the frame count 
and CRC5 into the dual-port RAM. 
For example, with a frame count of 
54h, the SOF packet passed to your 
uSIE is [04h,80h,A5h,54h,90h]. 

The pSIE input state machine reads 
in and shifts out these four bytes of data, 
then goes to the SEO state for two bus 
clock periods, then to the Idle or f state 
for one period, and then disconnects [9]. 

Congratulations! You've just com- 
pleted your first USB transaction. 

THE USB HUB 

The next step is a full-speed USB hub 
Control Read sequence. The '2040 
hub controller chip was enlisted to do 
all of the bus housekeeping functions, 
including line driving, slew rate control, 
hot-swap power management functions, 
and low-/full-speed device detect. This 
is a nonstandard use for this part, but 
it does the job and saves work in re- 
creating (as separate circuitry) all of 
the functions it performs. 

The '2040 is a USB slave controller 
and, before its functions can be ac- 
cessed, it must be initialized just as 
any other USB device. All USB hubs 
are full-speed devices, so the clock- 
generating section contains logic for a 
12-MHz full-speed clock signal. 

Fortunately, it's only necessary to 
talk to the '2040 hub to initialize it. 
Listening isn't required at this stage, so 
the first USB communication that the 
host controller will initiate is a full- 
speed Control Read sequence with its 
own '2040 hub. 



Note that in wiring the '2040 device, 
because control information is sent as 
a DC-level signal, it's crucial that you 
pay attention to the correct pull-up and 
pull-down resistors in your design. 

The Control Read sequence consists 
of a number of transactions, each con- 
sisting of the exchange of two or three 
packets. For example, the setup trans- 
action consists of a SETUP token packet 
followed by a DAT AO data packet and 
ending with an ACK handshake packet. 

At this point, a logic analyzer or 
storage oscilloscope becomes a necessity 
to monitor the serial signals going to 
and coming from the '2040. Monitor- 
ing ensures you're getting the right 
signals out to it, in the right order, and 
with the right timing, and lets you 
verify that the Control Read sequence 
is completing correctly. 

The first packet in the first transac- 
tion of the Control Read sequence is a 
SETUP packet. The SETUP token is 
interpreted by the hub the same as an 
OUT token. 

On powerup, all USB devices default 
to address OOh and endpoint OOh. These 
will be the initial ADDR and ENDP 
values for the TUSB2040 part. 

To get the CRC5 value for this or any 
SETUP, IN, or OUT packet, combine 
the ADDR and ENDP values to form an 
11 -bit address. Then use this value to 
offset into the CRC5 look-up table [10]. 

As with the SOF packet, building 
the SETUP packet starts with the micro- 
controller placing the ByteCount byte, 
then the sync and PID bytes, and two 
bytes for the ADDR, ENDP, and CRC5 
into the dual-port RAM. Your result 
should be [04h,80h,2Dh,00h,10h]. 

The purpose of this SETUP packet 
is to send a message to endpoint of 
the device at address to expect incom- 
ing data on the next packet out. But 
after getting this message packet, the 
receiving device will only listen for so 
long before timing out, which brings 
up the issue of bus turnaround time. 

The bus turnaround time is basically 
the time period (after the end of a 
packet's transmission) that any USB 
device still expecting to receive another 
packet will wait before "hanging up." 
The USB Specification calls for at least 
16 (but no more than 18) bus clock 
periods for this interval [1, p. 161]. 




•48 MH« USB S„.t.» Clock 



Power 


Tabl 




PART 


+ SU 


t-3. 3U 


GND 


Ul 


14 




? 


U3 


16 




IS 


U4 


12.34 




1.23 


US 


40 




20 


U6 


20 




13 


U7 


23 




14 


U8 


28 




14 


U9 


48 




24 


uie 


32 




15 


Ul J. 


21.34 




1,22. 43.64 


UI2 


12. 34 


64 


1 .23 


U13 


12.34 




1.23 


U14 






10 


U15 




20 


6.24 


U16 


2.3 


13.27 


1 


Ul? 






1.3,5,7 


UI8 


2.3 






U19 


2.3 




: 


U20 






1,3,5.7 


U2I 






1 






2 


1 



four bits of this byte are used for 
ByteCount and the upper four 
bits are used for control flag 
information [14]. 

With this modification, your 
uSIE will know from the Byte- 
Count byte that the SETUP 
packet expects no return hand- 
shake and that there's a second 
packet waiting in the dual-port 
RAM to be sent out before the 
bus turnaround time expires. 
This is probably the biggest 
single leap in your HDL code 
development, so expect to spend 
some time working through it. 



Figure 2— This schematic shows the host-controller support logic. The nets ADDR[00:15] and DB[00:07], left side of the 
dual-port RAM, connect to your 8-/16-M microcontroller. Programming for the three CPLD devices is available via ftp. 



The second packet in the Setup 
transaction is a DATAO packet. DATAO 
and DATA1 are the two packet identi- 
fiers used to distinguish data packets. 
The first data packet in any transaction 
is always labeled with the DATAO PID. 

The second data packet begins with 
the DATA1 PID, and the third with the 
DATAO PID. They then alternate be- 
tween DATA1 and DATAO, except for 
Control sequences, which end with the 
exchange of an empty DATA1 packet. 

BACK TO THE liSIE 

So far, the dual-port RAM read/write 
logic has only had to output one packet 
at a time. Because of the short bus turn- 
around time allowed for full-speed USB 
devices, your DATAO packet must be 
ready to go right after the SETUP packet 
is sent, which means it must already 
be in the dual-port RAM along with 
its associated SETUP token packet. 

That's just one example of the 
general case, that, given the short bus 
turnaround time, the host controller 
must be able to complete a full trans- 
action all at one time. 

On the microcontroller side of the 
dual-port RAM, transactions are stored 
in a semi-linked-list fashion (i.e., the 



ByteCount byte, which starts each 
data sequence, is used as an offset to 
the next ByteCount byte). If this count 
is zero, the SIE knows that no more 
data is to be sent and goes to an idle 
state until the beginning of the next 
1-ms frame clock. 

To keep the 8-/ 16-bit microcontrol- 
ler from causing conflicts by trying to 
access the same segment of the dual- 
port RAM at the same time as the uSIE, 
its memory is divided up into four 
256-byte pages [11]. Each page is in 
turn divided into 128-byte output and 
128-byte input segments [12]. 

The four memory pages form a 
cyclic queue, with the micro (via its 
I/O pins) keeping track of the current 
page the pSIE is on. While the uSIE is 
accessing the current page, the micro 
is writing to the output segment of 
the next page and reading from the 
input segment of the previous page. 

Along with these modifications to 
the dual-port RAM address control 
logic, changes have to be made to the 
uSIE programming. Two changes are 
the additions of an "expect return flag" 
and a "data ready flag" [13]. Because 
the value of ByteCount for low-speed 
transactions never exceeds 16, the lower 



INITIALIZING THE USB HUB 

This DATAO packet con- 
tains the USB device request 
information necessary to start 
the hub initialization process 
[1, chap. 9]. All USB devices 
must be initialized by the 
following minimum exchange 
of information. 

On startup, all USB devices 
default to ADDR so the host issues 
a GET DESCRIPTOR device request to 
the default control endpoint, ENDP 0, 
at ADDR 0. The device address is set to 
a new value and the device descriptor 
is requested again at the new address. 

The GET DESCRIPTOR request 
consists of [1, p. 176]: 

• byte 1— bmRequestType, 80h, device 
request 

• byte 2 — bRequest, 06h, request code 

• byte 3 — wValue, OOh, descriptor index 

• byte A — w Value, Olh, descriptor type 

• byte 5 — wlndex, OOh, not used 

• byte 6— wlndex, OOh 

•byte 7 — w Length, 12h, 18 bytes is 
standard descriptor length 

• byte 8— wLength, OOh 

As was the case for the 5-bit CRC, 
the microcontroller is responsible for 
generating the CRC data. A 16-bit CRC 
is generated using a simple algorithm 
combined with a look-up table [15]. 
Make sure that the two CRC 16 bytes 
are placed in the right order in the 
dual-port RAM to ensure that the 
resultant serial data clocks out correctly. 

The Setup transaction expects a 
handshake after the DATAO packet is 
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and an Out transaction. The next step 
is to write a test routine for your 8-/ 
16-bit micro to complete each trans- 
action (one per 1-ms frame period). 

THE FIRST IN TRANSACTION 

The first In transaction consists of 
an IN packet sent by the host controller, 
followed by a DATA1 packet from the 
hub. It ends with the host controller 
returning an ACK handshake packet. 

So far, the uSIE can only send 
packets; it can't receive them. Because 



clock, the DPLL skips tne rourtn 
phase clock state. This could pose a 
problem for any uSIE implementation 
that, like mine, uses this fourth phase 
clock signal. 

There are ways around this bug, 
but I haven't spent the time to fix it 
yet. So far, it hasn't presented any 
problems because the hub runs off the 
same 48-MHz clock as the uSIE, and 
low-speed transactions don't last long 
enough (in bit times) for this skipping 
of clock states to occur. 



neeu iu uc uctc^icu. 

A two-bit shift register helps ac- 
complish this detection. As the USB 
signal is clocked in, a comparison is 
made between the current and previ- 
ous signal states. If they are equal, a 1 
is clocked out; if not, a [19]. 

Bit unstuffing is just the reverse of 
bit stuffing. If the number of Is in a 
row equals six, the input NRZI decod- 
ing state machine is clocked once 
without clocking the input shift regis- 
ter [20]. This, in effect, throws away 
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Figure 3— Here you see an SOF packet lor Irame count 054h. followed by the Control Read sequence tor the TUSB2040's GET DESCRIPTOR device request. The actual 
USB signal is formed by shifting out, least significant bit first, in the order they appear and in NRZI fashion, the bytes shown in this diagram. 



the stuffed bit. Just a reminder here: 
input clocking is a shift-right least- 
significant-bit-first operation. 

After you have a decoded signal, 
you need to start looking for the Sync 
Pattern. Separating it from the data 
signal and detecting its end will enable 
the uSIE to lock to the correct timing 
for reading data bytes out of the serial 
input shift register. 

The scheme I decided upon was to 
look for the value 8h in the upper four 
bits of the input shift register [21]. 
But, you can't start looking too soon 
because the first few bits to come 
through the decoding process may be 
interpreted as a 1 preceded by Os. 

The first segment of the hub's 
descriptor comes as the following 
DATA1 packet of Sync Pattern, PID, 
data and crcl6: [80h,4Bh,12h,01h,00h, 
01h,09h,0Oh,OOh,08h,10h,7Bh]. If this 
is the data output you see from the 
'2040 (via your uSIE), then your input 
section is working correctly. 

The EOP SEO state is detected 
using a counter clocked in the 4x 
domain. For example, with 12-MHz 
full-speed transactions, the counter is 
clocked at 48 MHz [22]. 



The counter is gated by the i 
of a SEO state. If the counter detects 
two full bus clock periods, the E0P_ 
f 1 ag is set [23]. In my implementation, 
the ending Idle state is not detected. 

Because a host controller isn't 
allowed to return either a NACK or 
STALL handshake, the uSIE doesn't 
have to implement these functions [1, 
p. 151]. The only transaction responses 
the host controller can return are an 
ACK handshake for transactions that 
are completed correctly and a no- 
handshake return for transactions that 
don't complete correctly. 

The simplest choice is for the host 
controller to acknowledge everything 
and let the microcontroller take care of 
error checking and repeating a trans- 
action if and when errors occur. Since I 
chose this option, the handshake packet 
need not originate with the uSIE but 
can be generated by the 8-/ 16-bit micro 
and loaded into the dual-port RAM 
with all the other packets in a trans- 
action. An ACK packet is just the 
SYNC and PID bytes: [02h,80h,D2h[. 

To finish the In transaction, the host 
controller must issue an ACK hand- 
shake. If the EOP for the DATA1 packet 



has been detected successfully, the uSIE 
reads in the next packet to send horn the 
dual-port RAM (i.e., the ACK packet. 

The final transaction of any Control 
Transfer is the Status Stage, which is 
nothing more than the exchange of an 
empty DATA1 packet. Basically, it 
gives the sending party a chance to send 
a parting ACK or NACK response back 
to the receiving end [1, p. 155]. 

BURPING THE \iS\E BABY 

If all has gone right so far, you now 
have a uSIE correctly locking on to 
the incoming USB signal and output- 
ting data bytes in a coherent fashion 
from its serial-in parallel-out shift 
register. The next step is to get this data 
into the dual-port RAM in a way that 
is readable by the 8-/16-bit micro. 

There are two address counters in 
the dual -port RAM address logic — one 
for reading output data, one for writing 
input data. When the uSIE goes into 
receive mode, it captures the current 
write address but doesn't write to it. It 
then clocks the write address counter. 

As the uSIE inputs data and writes 
it out to the dual-port RAM, it keeps 
a count of the total number of bytes 
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are Control No-Data transactions. 
Setting this configuration value to the 
nonzero constant corresponding to its 
hub configuration gives the host access 
the '2040's hub controller functions. 

Once these functions are accessed, 
the host controller, using an Interrupt 
In transaction, can read the Port Status 
Change bit map at the '2040 hub's end- 
point 1 to see if any devices are attached 
[1, p. 262]. A GET PORT STATUS request 
returns specific information about a 
port's attached device. 

The SET PORT FEATURE request is 
then issued several times with different 
wValues until the hub and device are 
ready. For example, wValue 04h is reset, 
wValue Olh is port enable, wValue 08h 
is power on, and so on [1, p. 254]. 

Configuring the USB hub is an 
example of bus enumeration [1, p. 169]. 
At startup, all USB devices require the 
same initialization and configuration 
sequences and share almost all of the 
same standard device requests. 

When it detects the presence of a new 
device on the USB, the host controller 
enables an initial 100 mA of current to 
bus-powered devices. Next, there is a 
wait period for the attached device to 
power up and be ready to accept com- 
munications [1, p. 242]. This period is 
specified by bPwr0n2PwrGood, which 
is returned as part of a hub's Hub 
Descriptor [1, p. 250]. 

A RESET device request is sent to 
the hub controller the device is attached 
to. The hub then issues a standard USB 
RESET control signal, which is at least 
10 ms of the SE0 state [1, p. 119]. 

Following a reset, the first device 
request issued is always GET DESCRIP- 
TOR at ADDR and ENDP 0. Then, 



, U u U dvc access to all device requests 
specific to that configuration class. USB 
devices may support more than one 
configuration, so you must specify a 
particular configuration value during 
device initialization. 

The final step is to enable full power 
to those devices requiring more than 
the initial 100 mA of current. 

BACK TO USB SCHOOL 

Not every device supports every USB 
device request. There's a lot of infor- 
mation in chapters 8, 9, and 1 1 of the 
USB Specification that may be essen- 
tial for communications with your 
USB device: for example, variables like 
b Interval (the interval period, in 
frame counts, between device accesses) 
or bPwr0n2PwrGood (the time for a 
device's power supply to ramp up). 

Experiment with the standard de- 
vice requests by issuing them to the 
'2040. Having feedback from an actual 
USB device and comparing its responses 
to the Specification's text will help you 
make sense of the material. 

Low-speed transactions are prefaced 
by a special PID (PRE) sent at full speed. 
The uSIE doesn't append the usual EOP 
and Idle states when sending this low- 
speed preamble, but (after a pause of 
four bus cycle periods to give down- 
stream hubs time to reconfigure) goes 
from the PRE PID to the Sync Pattern 
of the next low-speed packet [1, p. 160]. 

ON YOUR OWN 

Now, plug a low-speed USB device 
into the host controller, power up, 
enable the device's features, and start 
teaching the attached micro to speak 
USB. Once the host controller is up and 
running, read the '2040's Port Status 



What those features are and how you 
talk to the USB device after configura- 
tion is device-specific [1, p. 34]. So, 
from here on out, you're on your own. 

I hope you'll take up the USB 
mantle, create your own embeddable 
low-speed USB host controller, and 
make your work available as HDL 
shareware. Happy USB'ing. S 

Glen Reuschling is a manufacturing 
engineer by day and a serious hobby- 
ist by night. His most recent home 
project resulted in this article. You may 
reach him at wildiris@cruzio.com. 



SOFTWARE 



Programming for the three CPLDs 
was done using the hardware descrip- 
tion language CUPL. Source code is 
on the Circuit Cellar web site. 
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